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When NASA was created in 1958 one of the elements incorporated into this new agency was the 
Army Ballistic Missile Agency (ABMA) in Huntsville, AL and its subordinate Missile Firing 
Laboratory (MFL) in Cape Canaveral. Under NASA, the MFL became the Launch Operations 
Directorate of the George C. Marshall Space Flight Center in Huntsville, but expanding 
operations in the build up to Apollo dictated that it be given the status of a full fledged Center in 
July, 1962[1]. The next year it was renamed the John F. Kennedy Space Center (KSC) after the 
president whose vision transformed its first decade of operation. 

The ABMA was under the technical leadership of Dr. Werner Von Braun. The MFL was run by 
his deputy Dr. Kurt Debus, an electrical engineer whose experience in the field began in the early 
days of V-2 testing in war time Germany. In 1952 a group led by Debus arrived in Cape 
Canaveral to begin test launches of the new Redstone missile [2], During the 50’s, The MFL built 
several launch complexes and tested the Redstone, Jupiter and Jupiter C missiles. This small 
experienced team of engineers and technicians formed the seed from which has grown the KSC 
team of today. 

This article briefly reviews the evolution of the KSC electronic technologies for integration, 
check-out and launch of space vehicles and payloads during NASA’s first 50 years. 


Mercury and Saturn 1 (1958-1963) 

Debus’ first job under NASA was the adaptation of the Redstone missile facilities to support the 
suborbital flights in the Mercury program. Complex 5 was converted to Mercury/Redstone (MR) 
facilities with relatively minor changes and during the Mercury Program the on-orbit operations 
were conducted in a nearby Cape facility (these were moved to the new Johnson Space Center for 
the Gemini and Apollo programs). 

The gantry, another name for any crane that straddles its payload, approached the vehicle from 
one side and provided access platforms including a small “white room” at the top for the entry of 
the astronaut. On the ground level, at four sides of the “boat-tail” were pipes for the passage of 
cables and flex hoses into sub-pad conduits. The blockhouse, a hardened bunker capable of 
withstanding an exploding vehicle, was sufficiently close that signal wires, relay power circuits 
and even pneumatic indicators could be routed directly from the vehicle to five “firing” consoles 
in the blockhouse. Most of the vehicle servicing was performed by hand including operating 
propellant valves, replacing batteries, setting inertial guidance systems, etc. so the consoles 
focused on vehicle systems more than ground support equipment (GSE). Console operators talked 
to missile technicians over an intercom system and could directly view their actions through large 
water filled windows in the blockhouse. The consoles contained about 100 readings including 
about 25 analog measurements. The MR telemetry system was 2 channels with 1 16 
measurements. During launch preparation, technicians at the vehicle, coordinated activities with 


1 



those on the consoles then the entire team retreated to the blockhouse for the final moments of the 
countdown. 

As an example of the detailed operations we review the first MR launch attempt; the unmanned 
MR-1. This was the only space vehicle launched twice (until Shuttle Columbia). During its first 
launch on November 21, 1960, the engine shut down shortly after lift-off when the primary 
electrical umbilical ejected at about 4 inches altitude. Loss of the electrical ground through the 
launch ring, and a longer than normal delay between ground disconnect and power disconnect, 
caused the engine activate relay to open shutting down the engine. The longer delay was due to 
the heavier vehicle and therefore slower rise off acceleration. The vehicle settled back onto its 
launch ring with the rocket control “drum timer” merrily clicking along thinking the vehicle was 
flying. At specific times, the launch abort tower ignited carrying it away to crash 400 feet from 
the pad, the bolts holding the capsule to the rocket blew, and the parachute deployed. The launch 
team stood helplessly staring at the vehicle through the blockhouse windows. After several hours 
the batteries died and the telemetry stopped. This also meant that the armed command destruct 
pyrotechnic explosives were safe. Engineers left the blockhouse and manually drained the 
propellants. Luckily winds were light so the parachute did not pull the rocket over. The remaining 
MR flights were very successful except for the loss of Gus Grissom’s capsule in the Atlantic in a 
still mysterious firing of the hatch. 

Concurrent with the Mercury program, the Launch Operations Directorate began the construction 
of the largest launch facility to date; Complex 34 (CX34) for the gigantic Saturn 1. This vehicle 
had two stages with multiple engines per stage, and would ultimately (as the Saturn IB) carry the 
Apollo spacecraft for orbital testing. The Saturn was 3 times the height of Redstone and produced 
10 times the thrust. The first Saturn rockets had dummy second stages filled with water. Later 
shots carried the S-IV stage, a large hydrogen/oxygen restart stage; a prototype of the stage that 
would propel the Apollo tandem spacecraft into trans-lunar injection. This later second stage, 
called the S-IVB, differentiated the Saturn 1 from the Saturn IB. 

Multiple engines meant complex engine sequencing and the need for a first stage hold-down and 
release system. The larger exhaust volume meant the small launch ring was replaced by a very 
large flame deflector structure. The height of the vehicle required a tall umbilical tower with long 
umbilical swing arms positioned far enough from the vehicle to avoid contact during a windy 
launch. The Saturn blockhouse required 21 consoles, many for the increasing complex ground 
support systems that required remote manual control. The telemetry stream for the first Saturn 
grew to 505 measurements in 8 links. As the Saturn program progressed, the data rates and 
bandwidth continued to expand. The dome shaped blockhouse eliminated windows, the Saturn 
had far too high a blast potential. Instead submarine periscopes (a USAF innovation) were used 
for test conductors and closed circuit television allowed console operators views of critical 
operations. For example, when an operator started filling a liquid oxygen tank, he could verify 
that vapors were streaming out the vent. 

CX34 started as the big brother of Complex 5. Controls and indications were still point-to-point 
with a great increase in remote control versus hands-on actions. As the vehicle matured and 
became more complex, increasing levels of automation were introduced. Marshall Space Flight 
Center introduced automation in Saturn checkout systems with the RCA 1 10 computer in test 
operations in Huntsville, and later installed them at CX34. The RCA was the first priority 
interrupt computer, which assigns different inputs as stacked priorities and stops the operations of 
low priority operations to service higher priorities. By the beginning of the Saturn IB program in 
1966, CX34 and the new dual launch pad CX37 check out activities were highly computerized 
although it was nearly entirely remote manual controls. Issues faced by CX34 engineers continue 
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to be debated today especially how to design for computer failures and manual safing of the 
vehicle. Having a live Saturn vehicle on the pad like the MR experience was unthinkable. Test 
data was transmitted from hardwire interfaces to ground support systems and the vehicle through 
600 kHz pulse code modulated FM links to dual RCA 110 computers, one for running the test and 
one for controlling displays. The telemetry link for Saturn 1 would grow to 1183 measurements 
[ 1 ]. 

The Saturn 1 experience with automation showed that computers were essential to complete the 
increasingly complex series of tests required to verify all vehicle and ground systems. This 
project also created a local team of experts that, in the future, would lead the development of 
major KSC automation systems. 

The Saturn 1/IB second stage used liquid hydrogen as a fuel. This required handling huge 
amounts of this rare and dangerous substance. At only 20 degrees Kelvin above absolute zero and 
with very wide air/vapor explosive limits, hydrogen challenged NASA’s ability to safely support 
test and flight operations. A small cottage industry in hydrogen fire and leak detection developed 
at KSC. CX34 saw the first use of a “home-made” mass spectrometer to detect hydrogen leakage 
in the second stage systems [3]. New fire detectors were required since commercial detectors 
were based on infrared sensing of the hot C02 bands and missed the hot H20 bands. These 
efforts became the basis for a highly technical engineering group that included both electronic 
engineers, chemists, and physicists that would develop increasingly sophisticated yet hardened 
and practical hydrogen and hypergol sensing systems at KSC. 

Complex 34 was the site for one of NASA’s greatest tragedies, the Apollo 204 fire which killed 
three astronauts in January 1967. Although the specific cause was not ascertained, the 
contributing factors included a high pressure pure oxygen environment for ground testing, 
excessive use of flammable materials in the cabin, a hatch that could not be opened quickly and 
the possibility of frayed wiring bundles at a small access hatch. Post fire investigations revealed 
many electrical problems in the spacecraft, which were subsequently corrected. On October 11, 
1968, Apollo 7 lifted off CX34. This was the first and last manned flight from CX34 and no 
manned launches were conducted from CX37. 

Saturn V (1963-1975) 

The Saturn V and Apollo spacecraft represented a major increase in check out test requirements. 
The Launch Control Center (LCC) was several miles from the launch pad which necessitated 
several changes. The data handling computers were mounted underneath the vehicle in the mobile 
launcher, called the Launch Umbilical Tower, so that tests could take place in the Vehicle 
Assembly Building, adjacent to the LCC as well as on the launch pad. The RCA 1 10A in the LCC 
could transmit 2,016 discrete signals to its brother in the LUT which could transmit 1,512 discrete 
signals back [4], The LCC contained 4 firing rooms so that four vehicle “flows” could be handled 
in parallel. Each firing room contained about 400 consoles. A new feature added to the previous 
architecture was an alert monitor system where out of tolerance measurements were picked up 
and displayed at a central location. 

Programming for the RCA 1 10A computers was performed in machine language. A higher 
language process called “Acceptance Test Or Launch Language” (ATOLL) was used to translate 
procedural steps into machine code. Another innovation was the testing of code against process 
simulators. This overall process improved procedures but inevitable conflicts arose between 
systems engineers and software engineers over the extent to which processes should be 
automated, i.e. how many contingencies can be hard coded into a flow chart versus the response 
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of a knowledgeable systems engineer. The compromise was often that only simple processes were 
fully automated (e.g. turn on a pump and verify that the pump has started and a nominal flow 
indication has occurred). 

The Firing Rooms also contained a DDP 224 display computer which controlled 20 data display 
CRT’s. This innovation, a precursor to future displays, allowed a significant increase in the 
density of data available on a console. 

The Saturn vehicles contained their own computers and were very much separate vehicles from 
the Apollo spacecraft. The astronauts did not “fly” the Saturn they rode it, so that the Command 
Module simply displayed status indicators of the launch vehicle. While the stages of the Saturn 
vehicles were checked out and integrated together on the LUT, the Apollo Command and Lunar 
Modules were checked out in a facility called the Manned Spaceflight Operations Building. Later, 
the acronym was softened a bit with its new name Operations and Checkout (O&C). The Apollo 
Command/Service Module and Lunar Module spacecraft were processed in the O&C high bay. 
Adjacent rooms housed a system called ACE, Apollo Checkout Equipment. KSC developed the 
concept and architecture for the ACE system. Approved for development in 1962, ACE paralleled 
ground and flight telemetry and proved itself in prototype phases as early as Cooper’s Mercury 
flight. This early start enabled concurrent development as the Apollo hardware was designed but 
also considerable evolution of hardware before configuration was frozen. General Electric (GE) 
became involved in ACE as part of their overall GSE development responsibilities. GE added to 
the knowledge base but also introduced conflicts of ideas. The system team weathered these and 
other storms and ACE became operational in 1964 in support of Apollo 009 build up in Downey, 
California, the first unmanned Apollo spacecraft to fly. One key feature of ACE was that the 
same hardware and software systems were used at the manufacturing facilities (Downey and 
Bethpage, New York) and at KSC. The ACE system was not only interfacing with systems on the 
spacecraft and GSE but was also interfacing with flight computers. ACE could enter a command 
to an on-board computer then verify that the internal spacecraft system responded. 

Space Transportation System (1976-Present) 

The Space Transportation System was envisioned to provide “assured and routine access to 
space.” The concept of the Space Shuttle as a space truck capable of 60 launches per year with 5 
vehicles [5] and minimum turn around time of 10 working days, 2 shifts per day, today seems 
shockingly aggressive. Plans also included the phasing out of all other heavy launch vehicles, 
Delta, Atlas, and Titan. These turn around requirements called for a quantum leap in check out 
and launch technology. The central player in this feat would be a new Launch Processing System 
(LPS) capable of highly automated testing and distributed in the facilities requiring check out 
activities, the Orbiter Processing Facility, the Hypergol Maintenance Facility, the VAB and the 
Pad’s. The LPS computers were installed in the Launch Control Center (LCC) where Firings 
Rooms 1 and 2 were converted for Shuttle operations. 

LPS architecture and capabilities were very advanced for the early 70’s when it was conceived. 
There would be roughly 40,000 inputs and outputs [6]. This I/O is handled by Hardware Interface 
Modules (HIM) operating (O) or sensing (I) relay contacts and digitizing analog measurements. 
The data sampling rate was programmable up to 50 kHz per channel. The data streams from each 
HEM were fed into Front End Processor computers which time tagged, bundled and converted 
data into engineering units. The FEP’s pushed the data into the massive Common Data Buffer 
(CDBFR) which contained the latest value of all of the LPS discrete and analog measurements 
and commands. Consoles in each firing room were driven by Modcomp Classic minicomputers 
whose architecture is based on interrupt programming. The Modcomps contained a series of 
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programs which the console operator could activate for displaying data or conducting an 
operation. The Modcomps fetched the data from the CDBFR for display, and pushed changes to 
the CDBFR for control. Data was displayed on color CRT’s using graphic “skeletons” 
representing the schematic of the particular system. Consoles were in clusters each containing a 
Master Console capable of performing the operations of any of the other consoles for back-up. 

For example a console operator could conduct a system test on an Orbiter system in the OPF then 
switch to testing another Orbiter at the Pad. Programs were written in a new language called 
Ground Operations Aerospace Language (GOAL). Test sequences were written as a series of near 
English spoken language statements and GOAL translated these into machine language. 

LPS also handled the complex timing issues associated with interfacing with the 5 Shuttle on- 
board computers. The Saturn vehicles had primitive sequential operation computers which could 
handle complex tasks like sequencing the start of multiple rocket engines, but the Shuttle was 
extremely automated and flown entirely via its computers. Launch preparations are mainly 
handled by LPS, but the actual launch is controlled by the Shuttle computers requiring a hand-off 
to the on-board system with sub-millisecond timing precision. This synchronization was a major 
accomplishment at the time. 

The early years of the Shuttle program proved the worth of LPS as each mission showed a 
declining number of days for process flow (landing to launch). Although schedule pressures were 
high, the original Shuttle vision appeared to be on track. The Challenger disaster of January 1986 
showed that schedule pressure had resulted in a culture of unresolved problems. Before Return to 
Flight, every system at KSC, including LPS and instrumentation systems was carefully 
scrutinized and failure modes re-evaluated. Safe operations, not schedule would now be the driver 
at KSC. 

Post-Challenger reviews of LPS identified new failure modes and improvements were 
implemented under a project called LPS Survivability. LPS became a stronger system but unlike 
cranes, cryogenics and other ground systems, LPS was fast becoming technically obsolete. The 
advances in computers and controls over the preceding decade were staggering including the 
introduction of micro-computer based industrial controls and desktop PC’s. Obsolescence is 
measured in many ways ranging from “how you would design the system today” to the inability 
to get spare parts. LPS was rapidly becoming obsolete by all these measures. Yet it continued to 
successfully process the Shuttle and does so to this day. This success is due to many factors, but 
is in part due to significant efforts made to reproduce boards, cards and components using modem 
technology; even to the point of proposing to reduce a Modcomp computer to a custom chip! The 
costs of replacing LPS would be enormous. It pervades all aspects of Shuttle processing at KSC 
and even if the hardware and software were free, the changes to procedures, verification of each 
process and all of the other systems engineering required would be difficult and expensive. A 
recent project called Extended LPS Survivability has resulted in a new Firing Room 4 where 
nearly all of the hardware has been replaced with modem, high reliability equipment. 

Two major attempts have been made to replace LPS. In the 1989 a contract with Harris Corp. 
called Core Electronics Contract Was initiated then subsequently (1994) cancelled due to Shuttle 
budget pressure [6]. Harris’ concept was to replace the primary LPS components with custom 
built replacements and use custom operating software although the plan called for porting the 
existing GOAL application software. Their study had concluded that network architectures for 
large scale real time control were not sufficiently mature. However, the largest project to replace 
LPS was the network based CLCS (Checkout and Launch Control System), initiated as an “in- 
house” project. CLCS was to produce a state-of-the-art critical control and monitoring system 
with an architecture that would allow incremental upgrades and adaptation as technology creates 
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new opportunities, thereby avoiding obsolescence. CLCS took advantage of significant 
technology improvements in the 3 years since Core to base its architecture on secure networks. 
After making significant progress, this project too was also cancelled in October 2002. CLCS was 
the largest development project taken on by KSC in the Shuttle operations era and its cancellation 
was in many ways regrettable. Since CLCS, no serious effort has been made to replace LPS nor 
would it make sense in the current reality of the phase out of Shuttle in 2010. 

Other limitations of LPS deserve mention. LPS was designed, in modem parlance, as a 
supervisory remote manual system with discrete control outputs. The Shuttle GSE was designed 
for control with discrete commands only. The only direct exception I’m aware of was a small 
closed-loop controller installed in the Environmental Control System, a launch pad vehicle 
cooling and purge system. The mass spectrometer-based Hazardous Gas Detection System also 
required a special HIM card developed (called an x-card) to translate LPS commands and 
indications to IEEE-488 format. In special cases huge efforts were made to implement a quasi- 
closed loop control such as in the liquid hydrogen replenish system which controls a valve on the 
Mobile Launcher to keep the hydrogen level near the full mark in the final hours of the 
countdown. 

Improvements to GSE systems increased pressure to add local closed loop controls. This and the 
continuing degradation of cabling patch-racks, in place since the early 60‘s led to a proposed 
Integrated Network Control System (INCS) in the 90’s. INCS would have implemented 
Programmable Logic Controllers with LPS being relegated to supervisory control and alarm 
function. The high costs for the system and the competition with CLCS for funds kept INCS on 
the back-burner for years until it was realized that much of the system could be installed 
piecemeal benefiting each GSE system in turn. The catch phrase at the time was “CLCS without 
INCS was like a digital dash-board in a Pinto.” INCS has been partially implemented and is 
expected to play a significant role in the architecture of Constellation GSE controls. 

At the inception of the Shuttle program efforts were made to continue to use Saturn V equipment 
to save funds. Notable among them was the large inventory of process transducers and hydrogen 
fire/leak detection technologies. Hydrogen fires are detected using UV flame detectors sensitive 
in the 1 80 nm range which use a photoelectric detector similar to a Geiger Mueller tube. 

Hydrogen gas leaks are sensed by conventional combustible gas detectors. These use a platinum 
coated thermister in a bridge circuit, and the rise in temperature on the coated bead indicates the 
presence of combustible hydrogen. Combustible gas sensors and UV fire detectors are placed at 
every flange on the hydrogen cross-country pipes and in special locations such as the crew cabin 
access arm. During the first launch attempt for STS-41D, a launch pad abort called for the main 
engines to shut down. The UV detectors indicated that a significant hydrogen leak from the 
engines was causing a large fire, invisible to the television cameras, that rose as high as the crew 
access arm thus causing mission managers to call for the crew to sit tight rather than evacuate into 
the hazardous environment. Unfortunately the UV detectors have suffered many problems 
including alarming on UV sky brightening and pipe reflections from the hydrogen flare stack. 

Hydrogen leakage in helium purged cavities (where bare liquid hydrogen lines are located) is 
detected using combustible gas sensors installed in a vacuum sampling loop system. The systems 
are calibrated and sense hydrogen concentrations from about 1000 ppm to well above the 
explosive limits. Hydrogen and oxygen leak measurements for the Orbiter engine compartment, 
and several other purged areas, is performed by the Hazardous Gas Detection System (HGDS), a 
mass spectrometer based detection system that measures concentrations of hydrogen, helium, 
oxygen, and argon (argon and oxygen together indicates an air leak, not a liquid oxygen leak). 

The initial Shuttle HGDS, called the Prime System was a marvel of technology at the beginning 
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of the program. The Prime used a scanning quadrapole instrument. Although designed to be 
manually operated in a laboratory, it was successfully modified for operation using primitive LPS 
controls from several miles away. During Challenger’s Flight Readiness Firing, prior to STS-6, 
very high HGDS readings indicated a massive hydrogen leak in the aft compartment. The 
controversy over the validity of the high readings was settled by re-performing the FRF which 
verified the leak. The HGDS is credited with saving Challenger before its maiden flight. After 
STS-51L Challenger, a second mass spectrometer was installed (the Back-up) using a more 
rugged and easier to automate magnetic sector system. Both systems suffered from “burps” 
caused by their ion pumps, one of which called a false scrub of a Shuttle launch, STS-93 in 1999. 
These and other problems stimulated a major system upgrade which occurred in steps; first a 
turbo-pumped mass spectrometer called HUMS was deployed in series with the existing units, 
then a major upgrade and replacement was completed in 2001 . 

Shuttle Payloads and International Space Station (1991-Present) 

To meet tight schedules payloads had to be fully tested against a Shuttle emulator before transport 
to the Orbiter Processing Facility or Pad for integration into the Shuttle. Spacelab modules and 
other cargo were processed in the O&C (horizontal payloads) or the Vertical Processing Facility 
(vertical payloads) using the Cargo Integration and Testing (CITE) system. CITE, actually part of 
the LPS, verifies that the GOAL software written for that particular payload was verified so that 
when the cargo left the processing facility it had been fully checked out and operated as if 
installed on the vehicle. 

In the post-Challenger era, the Partial Payload Checkout System (PPCU) was developed as a 
sophisticated, flexible, and distributed check-out system for Space Shuttle's widely diverse 
assortment of payloads. PPCU was first installed in 1989 and primarily consists of off-the-shelf 
hardware and software. The first version of PPCU was based on VME and Ethernet technology. 
PPCU was network based which allowed it to be more easily upgraded to keep pace with 
changing computer technology and payloads technologies. 

The nature and volume of Shuttle payloads associated with the construction and logistics of the 
International Space Station stimulated a new era of growth in KSC engineering and operational 
requirements. These included building the Space Station Processing Facility (SSPF) and its 
myriad of specialized ground support systems. The challenge was to process and check-out some 
of the most complex one-of-a-kind systems ever built and ensure they would perform flawlessly 
when first mated on orbit. The SSPF provides mechanical ground handling and electronic check- 
out systems that allow component interfaces to be fully explored, characterized, and validated. 

The Test, Control, and Monitor System (TCMS), whose architecture was heavily influenced by 
previous systems including PPCU and Core, provides the checkout of ISS elements. This system 
was activated in the mid-90’s. Originally the Program envisioned that ISS elements would arrive 
at KSC requiring minimal processing. Since there would very little interfacing to the Orbiter, 
minimal pre-launch check out would satisfy reliability requirements (“ship and shoot”). The KSC 
payloads community dissuaded the Program of that notion and showed that a check out system 
was required that would verify the near perfect functionality of ISS modules as they were mated 
in orbit. TCMS answers this need and has identified many discrepancies that would have required 
hardware to be returned from orbit for repair, and landing a fully loaded Orbiter is not something 
that’s particularly desirable. 

Constellation (Present and Future) 
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Large scale, secure, real time control systems can now be implemented using primarily 
commercially available equipment and software platforms. This is expected to significantly 
reduce the cost of processing the Orion spacecraft and Aries 1 booster. KSC is currently 
designing these systems. 

New sensor technologies have been developed for Shuttle, some of which were not implemented 
due to budget constraints. For example, we’ve shown that networked IR cameras can provide a 
significant upgrade to hydrogen flame detection systems. If the image processing software detects 
a fire, operators can actually view the image and verify that a fire exists. Mass spectrometers 
remain the best method for detecting low concentrations of hydrogen gas in purged spaces but 
KSC labs have made significant improvements in the size and costs of these systems. A new 
indicating tape has been developed that reversibly changes color when exposed to hydrogen gas. 
This material can be used in hazardous areas and viewed with television cameras to indicate 
leakage events. These technologies, many of which were not implemented under Shuttle due to 
budget pressures are expected to play a larger role in Constellation. 

Shuttle systems were designed by a team that had, in 15 short years, designed and activated 
ground architectures for Mercury/Redstone, Saturn, Saturn V, and Shuttle. With few exceptions, 
members of today’s KSC workforce have spent their careers enhancing existing Shuttle and 
payload operations. Today we face the challenge of developing complete processing architectures 
for new vehicles. The next several years promise to be very exciting as the post-Apollo 
generation grapples with these big issues and confronts the kind of challenges successfully 
overcome by our predecessors. 
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